达梦数据库

2024-05-28 11:11| 来源: 网络整理| 查看: 265

点击上方"达梦云适配中心"

关注我们吧！

在最近的某财政项目中，达梦的性能监控工具定位了一些慢SQL问题。针对这些问题，达梦专家和应用厂商一起采用了创建索引、优化视图、引进临时表等方法进行优化。

下面我们将展示一个典型问题——由“in”值过多导致的慢SQL，让我们一起来看看，高手是如何用达梦特有的事务级临时表解决的。

问题详情

在前段时间的项目中，出现了一个很典型的查询优化问题。在此跟大家分享问题分析及解决方法。

此例中SQL文本大小达1.8MB，如下：

select count(1)from V_XXXXXXXXXXXXXX twhere C1= '235432' and C2= '345436' and ( C3 = 'SADFDSGADFDSAFDSAFSAD' or C3 is null ) and ( id in ('ERTRTEWEB4DF2BE413523615EFDBA', 'ERTETRET2A7C44AE83EFEC5DD4169FA2', 'FF053E459ERTRETRETR755D70B6C1712', '057ERWTETETRETRETRRRD8738ED5D886', '0518C9DERWTRETRETREE63B5346B38B3', '3E50D3EF6ERTRERTRTREE6920014CD55', '421FA8BERTERTEWTEWRTREA1181A059A', '31E2F34EWRTREWRTE31F72CA0563E4C9', '356EWRTREWTREWGFD1BE5DB4A4A39BEE', ................此处省略数万行 '8BEE2AERTEWTR70885B6421166C3A6C5', '296E705ERTRETWHG456196D973439599') )

这是一个多表连接的比较复杂的视图，SQL的过滤条件里id列 “in” 了几万个常量（红框部分）。这条语句第一次执行需要12秒，第二次执行时间为毫秒级。

原因分析

上述两次执行时间的差别，说明该语句执行时间主要消耗在SQL硬解析上。由于项目中相关功能的并发量较大，这条慢SQL引发了严重的性能问题。

这个问题比较普遍。主要原因是开发人员图简单，对“in”列表里常量的个数没有评估。常量动辄数万，甚至数十万，这种SQL在并发量较大的情况下就是灾难。

优化思路

1. 创建一个事务级的临时表

CREATE GLOBAL TEMPORARY TABLE TMP_INLIST(　　　　ID VARCHAR(100) ) ON COMMIT DELETE ROWS;

2. 将需要参与过滤的常量值插入临时表

--addBatch()批量绑定参数INSERT INTO TMP_INLIST VALUES(?);

3. 改写SQL语句

select count(1)from V_XXXXXXXXXXXXXX twhere C1= '235432' and C2= '345436' and ( C3 = 'SADFDSGADFDSAFDSAFSAD' or C3 is null ) and ( id in (select id from TMP_INLIST) );

解决效果

按上述优化思路处理后，不管“in”列表里面有多少个常量，SQL解析的代价都是一样的，性能问题得到解决。在本例中，此条SQL首次执行时间由十几秒降至毫秒级。

作|者|介|绍

myth8860云适配中心《龙山溪笔记》专栏主理人十五年一线达梦数据库应用经验ITPUB国内数据库区版主达梦数据库践行者主持多个大型央企和金融行业数据库项目：国家电网、中国铁建、中国神华等金融行业推广：建设银行、湖北银行、武汉公积金等

更多精彩文章，请使用PC端访问达梦云适配中心-社区专栏↓↓↓

【本文地址】

公司简介

联系我们